1. Field of the Invention
The present invention relates, in general, to providing application functions over digital communication networks, and, more particularly, to software, systems and methods for facilitating and, at least partially, automating the creation or generation of Web services from existing Web services, application functions, and/or callable methods.
2. Relevant Background
It is hard to imagine networked computing without the Web, and the Web has succeeded where earlier hypertext schemes failed is most likely its simplicity and ubiquity. From a service provider's (e.g. an e-shop or e-commerce provider) point of view, if they can set up a Web site they can join the global community. From a client's point of view, if you can type, you can access services. From a service interface (e.g., an application programming interface (API)) point of view, the majority of the Web's work is done by three methods (i.e., GET, POST, and PUT) and a simple markup language (e.g., extensible Markup Language (XML)).
Recently, a substantial interest has developed in the business community in the field of Web services, and the Web services movement is driven by the fact that the advantages of the Web as a platform can be applied not only to information but also to services. The Web services movement has resulted in efforts from many companies to produce Web services, in efforts from most of the major companies in the Web products sector to develop products that enable developers to create and deploy Web services, and in efforts from consumer businesses to develop new Web services and to enable their existing systems as Web services.
Generally, a Web service is programmable application logic accessible using standard communication protocols, such as Internet protocols. Web services combine the best aspects of component-based development and the Web. Like components, Web services represent black-box functionality that can be reused without worrying about how the service is implemented. Unlike current component technologies, Web services are not accessed via object-model-specific protocols, such as the distributed Component Object Model (DCOM), Remote Method Invocation (RMI), or Internet Inter-ORB Protocol (IIOP). Instead, Web services are accessed via ubiquitous Web protocols and data formats, such as Hypertext Transfer Protocol (HTTP) and Extensible Markup Language (XML). Furthermore, a Web service interface is defined strictly in terms of the messages the Web service accepts and generates. Consumers of the Web service can be implemented on any platform in any programming language, as long as they can create and consume the messages defined for the Web service interface.
A few key specifications and technologies are usually encountered when building or consuming Web services. These specifications and technologies address: a standard way to represent data; a common, extensible, message format; a common, extensible, service description language; a way to discover services located on a particular Web site; and a way to discover service providers. XML is currently the most popular choice for providing a standard way to represent data. Most Web service-related specifications use XML for data representation. The Simple Object Access Protocol (SOAP) defines one lightweight protocol for information exchange, e.g., for providing an envelope around the XML document. Part of the SOAP specification defines a set of rules for how to use XML to represent data. Other parts of the SOAP specification define an extensible message format, conventions for representing remote procedure calls (RPCs) using the SOAP message format, and bindings to the HTTP protocol. SOAP messages can be exchanged over other protocols, but the current specification defines bindings for HTTP. A standard way to document what messages the Web service accepts and generates (e.g., to document a Web Service contract) is by using the Web services description language (WSDL), which is an XML-based contract language jointly developed by Microsoft and IBM that is widely supported by developer tools for creating Web services. Developers also need some way to discover Web services, and a Universal Description, Discovery, and Integration (UDDI) registry specifies a mechanism for Web service providers to advertise the existence of their Web services and for Web service consumers to locate Web services of interest.
Presently, most well-known Web services platforms communicate using HTTP or HTTPS with XML-based formats—specifically, SOAP, WSDL, and UDDI. SOAP is used for remote invocation and is a protocol specification that defines uniform ways of passing XML-encoded data. SOAP also defines a way to perform remote procedure calls (RPCs) using HTTP as the underlying communication protocol. UDDI is the trader of Web service and provides a directory service for Web services in the form of a UDDI registry. UDDI provides a mechanism for clients to dynamically find other Web services. In practice, businesses that want to publish or advertise a service (and its usage interfaces) register or publish the service with the UDDI registry. The published information typically includes binding information that provides technical details necessary to invoke a Web service, such as uniform resource locators (URLs), information about method names, argument types, and the like. Clients that want to obtain Web services of a certain kind use a UDDI interface or other device to query or find Web services in the UDDI registry and receive back locator or identification information for a service along with call-in requirements for invoking the Web service and/or binding an application to the Web service. Communications with the UDDI registry are typically XML-formatted information enveloped in SOAP messages that are sent using HTTP headers. Services are advertised using WSDL, which provides a way for service providers to describe the basic format of Web service requests over different protocols or encodings. WSDL advertisements include XML-formatted information describing what a Web service can do, where it resides, and how to invoke it, and WSDL advertisements are a subset of a UDDI service description.
Most efforts to develop Web services and to promote the use of Web services has emphasized the development of a Web services platform or architecture that is useful with the Internet and intranets. When a business, such as an e-commerce business, wants to provide a new Web service, developers typically start from scratch to create an application, and then manually package the application for use in a particular Web services platform (such as the platform discussed above). This manual creation process can be a relatively time-consuming and complicated process including creating a service, writing service description information or documents, providing transport technology (such as a SOAP message envelope), and publishing the new service as a Web service (such as registering the new Web service with a service registry such as a UDDI registry). Efforts to make existing application, application functions, or services available as Web services have been limited and have not been widely accepted or implemented.
Hence, there remains a need for an improved method and system for generating Web services from existing services or functions. Preferably, such a system and method would be at least partially automated and would allow a Web services developers to interactively create Web services from combinations or integrations of existing services or software modules that are reliable and readily available to existing or new applications and network clients.